Hierarchical data structures are well known in the field of computer architecture and software. An exemplary tree-branch-leaf paradigm may be used to label, locate, and/or categorize records, files, and other data objects within a computer. Perhaps the best-known example of a hierarchical data structure is the folder-subfolder-file metaphor of certain file storage systems. Categorizing files using nested folders allows users to collocate and access related files within a common subfolder, and to collocate related subfolders within a common folder. In addition to
Although most implementations of hierarchical data structures employ similar user interfaces and metaphors to represent these structures to end users, the mechanics of storing hierarchical information may vary greatly. For example, an implementation of the folder-subfolder-file metaphor will almost always be used when storing files as objects (i.e., collections of bits) in a memory. Folders and subfolders may be stored as additional objects in a memory, or merely as properties associated with the stored files.
When folders or categories are formed merely as properties of the objects they contain, then they may not otherwise exist, but for their association with one or more stored objects. One example of this folder-as-property implementation is a set of objects that are labeled using a hierarchy of categories and subcategories. Rather than the hierarchy being stored separately as a collection of objects in memory, a “category path” is stored with each object. One example of a category path is “Earth/USSR/Moscow.” In the implementation described, a particular citizen may have this path stored as a property. No other hierarchy exists in storage, and the hierarchy of citizens can only be reconstructed based on the collection of paths stored with categorized objects. Using such an implementation, an “empty” category (i.e., one without an associated citizen) is not possible. Every category must be associated with an existing citizen in order to exist. Other implementations that do not use folder-as-property may also wish to prevent empty or unused categories. The advantage of a folder-as-property implementation is that hierarchies can be made to implicitly vary over time. For example, if a citizen may have a property “Earth/USSR/Moscow” in the year 1985 and “Earth/Russia/Moscow” in 2006. By reconstructing the hierarchy based on the properties on objects in a system, we can implicitly determine which folders are relevant. For example, in 2006, no citizens have “Earth/USSR” in their paths, and so USSR should not exist as a folder until an object is assigned this as a property.
Current interfaces used to navigate and modify hierarchical data structures allow for the creation of “empty” folders or categories. A user is able to create as many folders or categories as he or she wishes without ever populating files or objects therein. In a folder-as-property implementation, such empty folders are impermissible, but existing user interfaces cannot easily prevent a user from creating them.
There is a need in the art for a user interface that enables the creation and manipulation of a hierarchical data structure while enforcing rules preventing the creation of empty folders and categories.